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Using 127-Bit IPv6 Prefixes on Inter-Router Links 

Abstract 
On inter-router point-to-point links, it is useful, for security and 
other reasons, to use 127-bit IPv6 prefixes. Such a practice 
parallels the use of 31-bit prefixes in IPv4. This document 
specifies the motivation for, and usages of, 127-bit IPv6 prefix 
lengths on inter-router point-to-point links. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6164. 
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Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


[RFC4291] specifies that interface IDs for all unicast addresses, 
except those that start with the binary value 000, are required to be 
64 bits long and to be constructed in Modified EUI-64 format. In 
addition, it defines the Subnet-Router anycast address, which is 
intended to be used for applications where a node needs to 
communicate with any one of the set of routers on a link. 


Some operators have been using 127-bit prefixes, but this has been 
discouraged due to conflicts with Subnet-Router anycast [RFC3627]. 
However, using 64-bit prefixes creates security issues that are 
particularly problematic on inter-router links, and there are other 
valid reasons to use prefixes longer than 64 bits, in particular /127 
(see Section 5). 
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This document provides a rationale for using 127-bit prefix lengths, 
reevaluates the reasons why doing so was considered harmful, and 
specifies how /127 prefixes can be used on inter-router links 
configured for use as point-to-point links. 


2. Scope of This Memo 


This document is applicable to cases where operators assign specific 
addresses on inter-router point-to-point links and do not rely on 
link-local addresses. Many operators assign specific addresses for 
the purposes of network monitoring, reverse DNS resolution for 
traceroute and other management tools, External Border Gateway 
Protocol (EBGP) [RFC4271] peering sessions, and so on. 


For the purposes of this document, an inter-router point-to-point 
link is a link to which only two routers and no hosts are attached. 
This may include Ethernet links that are configured to be point-to- 
point. Links between a router and a host, or links to which both 
routers and hosts are attached, are out of scope of this document. 


The recommendations in this document do not apply to the link-local 
address scope. 


3. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


4. Problems Identified with 127-Bit Prefix Lengths in the Past 


[RFC3627] discourages the use of 127-bit prefix lengths due to 
conflicts with the Subnet-Router anycast addresses, while stating 
that the utility of Subnet-Router anycast for point-to-point links is 
questionable. 


[RFC5375] also says the usage of 127-bit prefix lengths is not valid 
and should be strongly discouraged, but the stated reason for doing 


this is to be in compliance with [RFC3627]. 


Though the analyses in the RFCs are correct, operational experience 
with IPv6 has shown that /127 prefixes can be used successfully. 
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5. Reasons for Using Longer Prefixes 


There are reasons network operators use IPv6 prefix lengths greater 
than 64, particularly 127, for inter-router point-to-point links. 


5.1.  Ping-Pong Issue 


A forwarding loop may occur on a point-to-point link with a prefix 
length shorter than 127. This does not affect interfaces that 
perform Neighbor Discovery, but some point-to-point links, which use 
a medium such as the Synchronous Optical Network (SONET), do not use 
Neighbor Discovery. As a consequence, configuring any prefix length 
shorter than 127 bits on these links can create an attack vector in 
the network. 


The ping-pong issue happens in the case of IPv4 as well. But due to 
the scarcity of IPv4 address space, the current practice is to assign 
long prefix lengths such as /30 or /31 [RFC3021] on point-to-point 
links; thus, the problem did not come to the fore. 


The latest ICMPv6 specification [RFC4443] mitigates this problem by 
Specifying that a router receiving a packet on a point-to-point link, 
where the packet is destined to an address within a subnet assigned 
to that same link (other than one of the receiving router's own 
addresses), MUST NOT forward the packet back on that link. Instead, 
it SHOULD generate an ICMPv6 Destination Unreachable message (code 3) 
in response. This check is on the forwarding processing path, so it 
may have performance impact. 


5.2. Neighbor Cache Exhaustion Issue 


As described in Section 4.3.2 of [RFC3756], the use of a 64-bit 
prefix length on an inter-router link that uses Neighbor Discovery 
(e.g., Ethernet) potentially allows for denial-of-service attacks on 
the routers on the link. 


Consider an Ethernet link between two routers, A and B, to which a 
/64 subnet has been assigned. A packet sent to any address on the 
/64 (except the addresses of A and B) will cause the router 
attempting to forward it to create a new cache entry in INCOMPLETE 
state, send a Neighbor Solicitation message on the link, start a 
retransmit timer, and so on [RFC4861]. 


By sending a continuous stream of packets to a large number of the 
2^64 - 3 unassigned addresses on the link (one for each router and 
one for Subnet-Router anycast), an attacker can create a large number 
of neighbor cache entries and cause one of the routers to send a 
large number of Neighbor Solicitation packets that will never receive 
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replies, thereby consuming large amounts of memory and processing 
resources. Sending the packets to one of the 2^24 addresses on the 
link that has the same Solicited-Node multicast address as one of the 
routers also causes the victim to spend large amounts of processing 
time discarding useless Neighbor Solicitation messages. 


Careful implementation and rate-limiting can limit the impact of such 
an attack, but are unlikely to neutralize it completely.  Rate- 
limiting Neighbor Solicitation messages will reduce CPU usage, and 
following the garbage-collection recommendations in [RFC4861] will 
maintain reachability, but if the link is down and neighbor cache 
entries have expired while the attack is ongoing, legitimate traffic 
(for example, BGP sessions) over the link might never be 
re-established, because the routers cannot resolve each others' IPv6 
addresses to link-layer addresses. 


This attack is not specific to point-to-point links, but is 
particularly harmful in the case of point-to-point backbone links, 
which may carry large amounts of traffic to many destinations over 
long distances. 


While there are a number of ways to mitigate this kind of issue, 
assigning /127 subnets eliminates it completely. 


5.3. Other Reasons 


Though address space conservation considerations are less important 

for IPv6 than they are in IPv4, some operators prefer not to assign 

/64s to individual point-to-point links. Instead, they may be able 

to number all of their point-to-point links out of a single /64 or a 
small number of /64s. 


6. Recommendations 


Routers MUST support the assignment of /127 prefixes on point-to- 
point inter-router links. Routers MUST disable Subnet-Router anycast 
for the prefix when /127 prefixes are used. 


When assigning and using any /127 prefixes, the following 
considerations apply. Some addresses have special meanings, in 
particular addresses corresponding to reserved anycast addresses. 
When assigning prefixes (and addresses) to links, care should be 
taken to ensure that addresses reserved for such purposes aren't 
inadvertently assigned and used as unicast addresses. Otherwise, 
nodes may receive packets that they are not intended to receive. 
Specifically, assuming that a number of point-to-point links will be 
numbered out of a single /64 prefix: 
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(a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be 
assigned as unicast addresses, to avoid colliding with the 
Subnet-Router anycast address [RFC4291]. 


(b) Addresses in which the rightmost 64 bits are assigned the 
highest 128 values (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: 
ffff) SHOULD NOT be used as unicast addresses, to avoid 
colliding with reserved subnet anycast addresses [RFC2526]. 


7. Security Considerations 


This document does not have inherent security considerations. It 
does discuss security-related issues and proposes a solution to them. 
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